home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000036_icon-group-sender _Wed Sep 16 16:47:34 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA10682
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 16 Sep 1998 16:47:33 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA04920; Wed, 16 Sep 1998 16:47:05 -0700
  7. Date: Wed, 16 Sep 1998 18:11:17 -0400 (EDT)
  8. From: cwills@bix.com
  9. Subject: RE: Context Switching
  10. To: icon-group@optima.CS.Arizona.EDU
  11. Message-Id: <9809161811.memo.79389@BIX.com>
  12. X-Cosy-To: icon-group@optima.CS.Arizona.EDU
  13. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  14. Status: RO
  15.  
  16. I think that the crux of the issue is that the current (and as far as I
  17. know only) implementation of Icon is what we currently have to work with.
  18.  
  19. As such... the current implementation uses C as the underlying language
  20. in which the Icon runtime libraries are written in.  Most of Icon actually
  21. runs within the runtime library itself, alot of data is saved on the
  22. C stack within many of the builtin functions that are generators (ie: find,
  23. upto, etc.)  The way that these builtin generators are written is to 
  24. re-invoke the interpreter recursively (adding another layer on to the
  25. C stack).  So... within the current implementation of the Icon VM, 
  26. the easiest and most efficient method to perform a co-expression switch
  27. is to perform a full context-switch by flipping the C runtime stack.
  28.  
  29. Is this a *bad* thing to do.... not really... it turns out the this is
  30. a fairly efficient method of performing the stack switch.  I've implemented
  31. the co-switch routine in two different architectures, and 4 different 
  32. compilers, and I never had that much problem with co-switch (in fact I 
  33. believe that the SAS C now has as part of its distributed runtime
  34. library for the IBM Mainframe C, a set of co-routine functions that
  35. perform the exact same context switch that happens with co-switch.
  36.  
  37. One must also remember that you are talking about the Icon Virtual Machine
  38. implementation itself.  If one steps back and takes a look at the
  39. I-Code instructions (the same thing as the "java byte code"), the details
  40. of context switching is left to the I-VM.  I also suspect that if one
  41. digs deep enough into the Java VM implementations, one will find all sort
  42. of mean nasty and ugly things to tweak out that last bit of performance.
  43.  
  44. If one where to redesign and reimplement the I-VM, (such as in JCON) then
  45. different facilities could be used.
  46.  
  47. Cheyenne
  48.  
  49. PS....
  50.  
  51. If you think that rswitch.asm is bad... just be glad that the good folks
  52. at the Icon Project re-wrote the interpreter around version 5.10, 6, 
  53. or somewhere... in that implementation the Icon stack frame was inter-mixed
  54. with the C stack frame, the interperter loop was written in assembler,
  55. garbage collection routines knew how to traverse around the C stack
  56. frames and find the Icon stack frame portions.
  57.